Field of the Invention
The present invention generally relates to a memory management controller for applications such as virtual machines. More specifically, a technique selectively shifts physical memory size of each application runtime environment (ARE) to allow a performance of each currently-operating application runtime environment to be calculated using memory usage data reported from inside the application runtime environment, and memory is then reallocated so that all collocated application runtime environments have the same relative performance slope, thereby providing a mechanism that utilizes the total memory resource of the system as fairly allocated among all the currently-operating application runtime environments, based on current memory needs.
Description of the Related Art
As is well-known in the art, a virtual machine (VM) is a software implementation of a machine (e.g., a computer) that executes programs like a physical machine. A hypervisor or virtual machine monitor (VMM) creates and runs virtual machines, including memory allocation for the VM, and can be computer software, firmware, or hardware.
A computer on which a hypervisor is running one or more virtual machines is defined as a “host machine”, and each virtual machine is called a “guest machine”. The hypervisor presents the guest operating systems with a virtual operating platform and manages the execution of the guest operating systems. Multiple instances of a variety of operating systems may share the virtualized hardware resources
As an initial matter, although the present invention is described in the environment of Java virtual machines (JVMs), there are many other virtual machine environments, so the methods described herein should not be considered as being limited to this specific environment. Any virtual machine or other application runtime environment that has internal metrics available through an interface, such as interface extensions, that can be sufficiently correlated with current performance of that virtual machine operation would potentially benefit from the method described by the present application. Some possible non-limiting examples of other runtimes are: V8 (Google's JavaScript engine), Ruby, Python, and C-sharp (Microsoft).
Perhaps even more significant, even though the exemplary embodiment described herein refers to JVMs, the method and structure of the present invention is not even constrained to constructs in a virtual environment. Rather, the present invention is considered as directed to any “application runtime environment” that has an interface that permits the reporting of internal memory parameter values of that environment to be reported externally. For purpose of the present invention, an “application runtime environment” is intended to refer to any process, as being executed on a computer, for which dynamic memory allocation is provided by a mechanism that is typically external to the environment itself, although the present invention can be expanded to be implemented in application runtime environments that internally provide memory allocation functions. Thus, a VM or a JVM would be specific instances of application runtime environments.
Thus, in addition to JVMs, the present invention, as implemented as the exemplary embodiment described herein, would also be directed to other types of virtual machines, as well as other types of applications running on a platform, or any other environment having memory allocations during runtime, as long as the environment has an interface that permits internal parameter values to be reported outside that environment. For example, certain containers such as Linux containers would be a non-limiting example of such application runtime environments that could potentially benefit from the techniques described in the present invention.
However, returning to the exemplary example involving JVMs, in recent years there has been widespread use of the Java virtual machine (JVM) as a server platform. Matching real memory and CPU resources to the time varying memory-processor demand footprint of applications is an important element in systems performance management, but there are issues associated with JVM memory management.
For example, even a single JVM configuration can have an issue in that the single JVM may take all the allowed memory (e.g., the heap size limit) but there is no performance benefit for such large physical memory consumption. Additionally, a single JVM may take memory from the OS but may not need it later when its workload changes. For configurations involving multiple collocated JVMs, one or more of the JVMs may take or reserve much more memory than is necessary.
One existing solution to manage JVM memory assumes that the JVM workload is instrumented to measure performance, but such performance instrumentation is typically not available and, even if available, the interpretation is domain specific and it is therefore difficult to devise a general solution.
Another disadvantage is that existing solutions fail to provide global optimization of memory resources. Even if an attempt is made so that each JVM is given enough memory to avoid a performance drop, severe shortage still results in swapping of memory. Conventional solutions are based on how much memory a JVM takes, but a JVM may not even benefit from additional memory.
Active sharing of processors between applications within and across virtual machines (VMs) in response to demand is a mature feature of the operating systems and hypervisors. Active sharing of memory (ASM) is analogously similar, in that ASM is a capability where physical memory pages move seamlessly between applications and across virtual machines to satisfy demand.
This technique improves system-wide memory utilization, or alternatively increases the application density or workload intensity hosted on a computer system. ASM is sometimes referred to as “logical memory over-commit”, as it reduces the total amount of memory necessary in a system with time varying workloads from the sum of the maximum demand of each workload to the maximum of the sum of the workloads.
The ASM technique is, however, distinguished from paging, which requires saving and restoring state in order to reuse pages from processes or VMs. Exploiting ASM requires the ability to identify unused memory in applications and operating systems and to map or re-map those pages to collocated applications, or to move them to another VM on a common hypervisor. This page reassignments widely available at the VM-hypervisor layer in the commercial space.
However, support at the application layer has been lagging as traditional application design and coding practice has not emphasized the need to dynamically return memory from the process space to the OS.